Conventionally, there was used a method of a navigation terminal detecting a current location, i.e. an origin, through connection with a Global Positioning System (GPS) and computing a route based on a destination of a trip input by a user. In recent years, however, there has been utilized a service method of providing route information, real-time traffic information related to the route, and various other kinds of information from a server that provides traffic information and route information using Personal Navigation Devices (PNDs) in a mobile communication network according to population and improvement in performance of smart phones.
In particular, various kinds of navigation services are being now provided and Open Mobile Alliance (OMA) is standardizing a Dynamic Navigation Enabler (DynNav) that transmits real-time traffic information in a Peer to Peer (P2P) mode through an Internet Protocol (IP)-based network of a mobile communication network or a wireless network instead of a method of transmitting Traffic Protocol Expert Group (TPEG) information in a Digital Multimedia Broadcasting (DMB) network that provides information in a conventional broadcast form. In this standard, a navigation terminal and service of a smart phone is mainly classified into two forms.
In the first form, complex route computation is not performed by a navigation application equipped in a smart phone but is performed by a server that provides traffic information and route information and a corresponding route is transmitted to the smart phone. The second form is applied to a case in which route computation is performed by an application equipped in a smart phone according to the improvement in performance of the smart phone or a case in which a navigation terminal having a mobile communication modem mounted thereto perform route computation. In the second form, route information is not transmitted by a server that provides traffic information and, when a route computed by the terminal is registered with the server, only real-time traffic information related to the registered route is received from the server in a customized fashion in an IP-based P2P mode instead of a conventional broadcast form.
FIG. 1 is a view showing classification of a navigation device. The navigation device may be classified into a form 110 that additionally transmits TPEG-based traffic information transmitted through a broadcast network, such as DMB, a form 120 that additionally transmits traffic information based on IP, such as a mobile communication network or Wi-Fi, and a standalone form 130 that tracks location of a vehicle through connection with a GPS without connection with other communication media to create and provide route information.
In addition, the DynNav, which is being standardized by an open mobile alliance location working group (OMA LOC WG), belongs to the form 120 that transmits IP-based traffic information. More specifically, the DynNav belongs to a form that transmits traffic information in a P2P mode. In the DynNav, the navigation device is classified into the following two devices.
1. Smart ND: A device that can perform route computation and, therefore, requests only real-time traffic information without receiving route information through a DynNav server
2. Lightweight ND: A device that cannot perform route computation and, therefore, requests all kinds of real-time traffic information including route information through a DynNav server
In a conventional DynNav system, a procedure of requesting and transmitting corresponding traffic information is performed in a RESTful mode. As a result, the following route information types may be used. Each information type may be defined through XML Schema Definition (XSD).
1) Trip Structure: Information that a terminal initially receives from a user to set a route. Information basically having the same origin and destination is acquired and then transmitted to a server. The trip structure includes a subset corresponding to a plurality of route structures.
TABLE 1ElementTypeOptionalDescriptionoriginWGS84Location_PointYesLocation information of an origin expressed asWGS84 (Location_Point structure is defined intpeg-locML [TTI LOC]. At least one elementoriginWGS84 or originAddress MUST bespecified.)originAddressCivic Location FormatYesLocation information of an origin expressed in aCivic Location Format (Civic Location Formatis defined by IETF [RFC 5139]. At least oneelement originWGS84 or originAddress MUSTbe specified.)destinationWGS84Location_PointYesLocation information of a destination expressedas WGS84 (Location Point structure is definedin tpeg-locML [TTI LOC]. At least one elementdestinationWGS84 or destinationAddressMUST be specified.)destinationAddressCivic Address FormatYesLocation information of a destination expressedin a Civic Location Format (Civic LocationFormat is defined by IETF [RFC 5139]. At leastone element destinationWGS84 ordestinationAddress MUST be specified.)waypointsLocation_PointYesLocation information of an en route stop[0 . . . unbounded](described in WGS84 format) (Location_Pointstructure is defined in tpeg-locML [TTI LOC].)startingTimexsd:dateTimeYesStarting time of navigation service (schedulednavigation service time is specified as servicestarting time when the service starting time isspecified (Planned trip) and current time isspecified as service starting time when theservice starting time is not specified (Startingtime of the planned trip. If not present, currenttime is assumed.)tollRoadxsd:booleanYesConfirming whether going via a toll road isallowed (If true or not present, toll road areallowed.)vehicleTypeVehicle_InfoYesInformation of vehicle under operation(Vehicle_Info structure is defined in tpeg-rtmML [TTI RTM])calculateRoutexsd:booleanYesConfirming whether a route computed by aserver is provided (If false or not present, servershould not propose routes.)linkcommon:LinkYesLink information for routes defined in a trip[0 . . . unbounded](Links to routes related to the trip. Attribute“rel” must be set to “Route”.)resourceURLxsd:anyURIYesSelf-referring URL information (Self-referringURL. SHALL NOT be included in POSTrequests, MUST be included in responses to anyHTTP method that returns an entity body, and inPUT requests.)
2) Route Structure: A mode to express all routes computed through the trip structure. The route structure is expressed as several segments.
TABLE 2ElementTypeOptionalDescriptiontravellingTimexsd:floatYesRoute travelling time (Total travelling time (inminutes) for the route)distancexsd:floatYesTotal route distance (Total distance (in Km) of theroute)originLocation_PointNoStart point of a route (expressed in a WGS84 format)(Location_Point structure is defined in tpeg-locML[TTI LOC].)segmentSegmentNoEach segment constituting a route (Sequence of road[1 . . . unbounded]segments that form the route)trafficEventsCategorizedEventListYesLink information approaching traffic informationReferenceresources (List of traffic events as defined in tpeg-[0 . . . unbounded]rtmML [TTI RTM], grouped into categories.)linkcommon:LinkYesReference to the route for which it is proposed asalternative. Attribute “rel” must be set to “Route”.resourceURLxsd:anyURIYesSelf-referring URL information (Self-referring URL.SHALL NOT be included in POST requests, MUSTbe included in responses to any HTTP method thatreturns an entity body, and in PUT requests.)
3) Segment Structure: A structure expressing each segment. Length of each segment and a real-time traffic situation corresponding to a corresponding segment may be defined in a TPEG format.
TABLE 3ElementTypeOptionalDescriptionendPointLocation_PointNoEnding point information of each segment (expressedin a WGS84 format) (Location_Point structure asdefined in tpeg-locML [TTI LOC]. The starting pointof the segment should be assumed equal to the endingpoint of the previous segment (or the trip origin forthe first segment))midwayPointLocation_PointYesLocation_Point structure as defined in tpeg-locML[0 . . . unbounded][TTI LOC].linkNamexsd:stringYesName information of a segment (Name of the roadthat the segment belongs to)distancexsd:floatYesSegment length (Length of the segment in km)travellingTimexsd:floatYesAverage travelling time of each segment (Estimatedtime to cover the segment expressed in minutes, itincludes regular travelling time and delay)delayxsd:floatYesDelay or congestion time of each segment (Estimateddelay along the segment expressed in minutes)speedxsd:floatYesPossible average section speed information of avehicle in each segment (Estimated speed along thesegment expressed in m/s)performancexsd:stringYesInformation regarding a traffic situation (Levels of theinformation may be expressed as delay, congestion,and serious delay) (Description of traffic conditionsalong the segment. This field should be encodedaccording to tpeg rtmML definition [TTI RTM].)
In such an IP-based route provision method, it is necessary to perform a procedure of providing or acquiring the route in a case in which in a case in which a destination of a trip is location of a third party. In particular, it is necessary to provide a method of providing route information to the terminal since the location of the third party is changed.